properly handle revision based_on field

[escattone]

mozilla/sumo#2262

Notes

This PR takes care of properly handling the based_on field within the delete user pipeline.

• Revisions of parent documents
  • The based_on of these revisions currently gets set to either null (if no prior revision yet exists) or some other prior revision within the same document. It's never used after that, but it does get set. So when we delete un-approved revisions of parent documents, we risk deleting not only other revisions via the based_on cascade, but the entire parent document because the chain of cascades often reaches the current_revision, which then pulls in the document.
  • In this PR, if we're about to delete an un-approved revision that is the based_on of one or more revisions of parent documents, we prevent the cascade deletion of these by setting their based_on to None.
• Revisions of translations
  • The based_on of these revisions is always set to a revision within the translation's parent, but should always refer to an approved revision.
  • No changes here. We allow the cascade delete via based_on because if its based_on refers to an un-approved revision, it should be deleted.

[akatsoulas]

I would prefer to avoid having based_on revisions set to null upon deletion to avoid dangling revisions. How about treating this like a linked list of sorts?

• Identify all revisions that reference the to-be-deleted revisions
• Get the based_on value of the to-be-deleted revision
• Update the referencing revision to point to this predecessor
• If the to-be-deleted revision has no predecessor or it's the base of a translation set based_on=NULL
• Add a textfield/jsonfield to populate on deletion that explains the changes to the revision, something like previously was based on revision_id X created on Date. Modified during user deletion Y

Ideally this approach is simple and consistent and preserver the revision history and documents the changes.